3.1.1.  OGC SensorThings API

The OGC SensorThings API Standard provides an open and harmonized way to interconnect devices, applications, and data over the web and on the Internet of Things (IoT) (OGC 18-088). At a high level the SensorThings API provides two main parts, namely Part I — Sensing, and Part II — Tasking. The Sensing part of the Standard provides a way to manage and retrieve observations and metadata from different sensor systems. The Tasking part of the Standard provides a way for tasking IoT devices, such as actuators and sensors. The SensorThings API follows REST principles and uses JSON for encoding messages as well as Message Queuing Telemetry Transport (MQTT) for publish/subscribe operations.

3.1.2.  OGC API — Features

The OGC API — Features Standard offers the capability to create, manage, and query spatial data on the Web. The Standard specifies requirements and recommendations for Web APIs that are designed to facilitate the sharing of feature data. The specification is a multi-part standard. Part 1, labelled the Core, describes the mandatory capabilities that every implementing service has to support and is restricted to read-access to spatial data that is referenced to the World Geodetic System 1984 (WGS 84) Coordinate Reference System (CRS) (OGC 17-069r4). Part 2 enables the use of different CRSs, in addition to the WGS 84 (OGC 18-058r1). Additional capabilities that address specific needs will be specified in additional parts. Envisaged future capabilities include, for example, support for creating and modifying data, more complex data models, and richer queries.

3.1.3.  OGC API — Tiles

OGC API — Tiles specifies a Standard for Web APIs that provide tiles of geospatial information (OGC 20-057). The Standard supports different forms of geospatial data, such as tiles of vector features (colloquially called “vector tiles”), coverages, maps (or imagery), and potentially eventually additional types of tiles of geospatial data.

Vector data represents geospatial objects such as points, lines, and polygons. Tiles of vector feature data (i.e., ‘vector tiles’) represent partitions of vector data covering an area (e.g., lines representing rivers in a country).

In this context, a map is essentially an image representing at least one type of geospatial information. Tiles of maps (i.e., map tiles) represent subsets of maps covering an area.

3.1.4.  OGC API — Environmental Data Retrieval

The OGC API — Environmental Data Retrieval (EDR) Standard provides a family of lightweight interfaces to access Environmental Data resources. Each resource addressed by an EDR API maps to a defined query pattern. This Standard identifies resources, captures compliance classes, and specifies requirements which are applicable to OGC Environmental Data Retrieval API’s. This Standard addresses both discovery and query operations. Discovery operations enable the API to be interrogated to determine its capabilities and retrieve metadata about the published resource. Query operations allow Environmental Data resources to be retrieved from the underlying data store based upon simple selection criteria, defined by this standard and selected by the client.

Version 1.1 of OGC API — EDR has been published (OGC 19-086r6). The EDR API Standards Working Group (SWG) has recently obtained approval to publish Part 2 of the Standard: “OGC API — Environmental Data Retrieval — Part 2: Publish-Subscribe workflow” ([bib_edrpart2]). The focus of the EDR API-related work in this code sprint is therefore on the use of Part 2 of the Standard. Work continues on defining improvements to Part 1: Core Version 1.1 to be known as Version 1.2.

3.1.5.  OGC API — Processes

The OGC API — Processes Standard supports the wrapping of computational tasks into executable processes that can be offered by a server through a Web API and be invoked by a client application (OGC 18-062r2). The standard enables the execution of computing processes and the retrieval of metadata describing the purpose and functionality of the processes. Typically, these processes execute well-defined algorithms that ingest vector and/or coverage data to produce new datasets.

OGC API — Processes — Part 2: Deploy, Replace, Undeploy (draft) extends the core capabilities specified in OGC API — Processes — Part 1: Core ([OGC_18-062r2]) with the ability to dynamically add, modify and/or delete individual processes using an implementation (endpoint) of the OGC API — Processes Standard.

3.1.6.  Training Data Markup Language for Artificial Intelligence

TBA

3.1.7.  OGC CoverageJSON

TBA

3.2.1.  OGC API — Connected Systems

TBA

3.2.2.  OGC API — Maps

The OGC API — Maps candidate Standard describes an API that can serve spatially referenced and dynamically rendered electronic maps ([bib_ogcapimaps]). The specification describes the discovery and query operations of an API that provides access to electronic maps in a manner independent of the underlying data store. The query operations allow dynamically rendered maps to be retrieved from the underlying data store based upon simple selection criteria as defined by the client.

3.2.3.  OGC API — Records

The OGC API — Records candidate Standard provides discovery and access to metadata records that describe resources such as features, coverages, tiles / maps, models, assets, datasets, services, or widgets ([bib_ogcapirecords]). The candidate Standard enables the discovery of geospatial resources by standardizing the way collections of descriptive information about the resources (metadata) are exposed. The candidate Standard also enables the discovery and sharing of related resources that may be referenced from geospatial resources or their metadata by standardizing the way all kinds of records are exposed and managed.

3.2.4.  OGC API — Discrete Global Grid Systems

TBA

3.2.5.  OGC Features and Geometries JSON (JSON-FG)

The draft OGC Features and Geometries JSON (JSON-FG) Standard extends the GeoJSON format to support a limited set of additional capabilities that are out-of-scope for GeoJSON but that are important for a variety of use cases involving feature data ([bib_jsonfg]). In particular, the JSON-FG Standard specifies the following extensions to the GeoJSON format:

3.2.6.  DGGS JSON and UBJSON

TBA

3.2.7.  OGC CartoSym

TBA

3.3.1.  MapML

TBA

3.3.2.  ISO 19157-3

To facilitate dataset comparisons, evaluations and data quality reports (metadata or a quality evaluation report) have to be expressed in a comparable way, and it is necessary to have a common understanding of the data quality measures that have been used. An example of such common understanding of a standard quality measure is defined in ISO 19157-1:2023 Geographic information — Data quality — Part 1: General requirements. This standard defines the structure of a data quality measure as well as all additional attributes describing a data quality measure — see in …​. [insert Figure from here: https://github.com/i2vana/ISO19157-3/blob/main/OGC-CodeSprint/img/ISO19157-1_dataQualityMeasure.PNG]

To comply with current best practice for sharing data over the web, these measures have to reside in a machine-actionable data quality measures register. Such register is currently under development at ISO/TC211 and OGC. ISO 19157-3 Geographic information — Data quality — Part 3: Data quality measures register will be the standard defining the components and content structure of a register for data quality measures, and the registration and maintenance procedure. All of this is compliance with ISO 19135 Geographic information — Registration and registration procedures, a governing standard for all ISO/TC211 registers. The measures will be hosted in the ISO 19157-3 register will be hosted at OGC, the Registration Authority of ISO 19157-3. Current version implemented at OGC RAINBOW contains first set of 80+ recognized standard data quality measures (e.g. such as the Root Mean Square Error used for evaluation positional accuracy, or the Misclassification Matrix used to evaluate the attribute accuracy) and these were used in first few tests as part of the Code Sprint. Full version of the ISO 19157-3 Data Quality measures register is expected to be published together with the ISO 19157-3 standard in early 2026.

3.4.1.  CREAF Miramon

TBA

3.4.2.  QGIS

The QGIS stable release V3.28.6-Firenze, and later versions, has a Time Slider/Controller added to the menu bar. It behaves like a video controller if relevant to the data being displayed.

This and later versions also support the OGC API-EDR queries via a plugin.

Release V3.37 and later now supports a Vertical Slider for data and layers that have a vertical extent.

Figure 2 — Screenshot of QGIS Time Controller

Figure 3 — Screenshot of QGIS EDR Plugin menu

3.4.3.  Status of OGCAPI SourceType support in QGIS

QGIS supports adding a Raster or Vector Layer, using an OGC API Source Type. Under the hood, QGIS uses the OGCAPI GDAL driver. During this code sprint, this functionality was tested for different OGC APIs, in order to figure out what is working and to try to understand if the issue is on GDAL or QGIS.

An issue with relative links was identified on GDAL, which was affecting all the APIs. The issue was already fixed and is described here.

The current status (using QGIS version 3.39.0-Master QGIS code revision 399f7df1c7 and GDAL/OGR version 3.10.0dev-126a88523a) is:

Figure 4 — Screenshot an OGCAPI - Maps collection from Gnosis on QGIS

Figure 5 — Screenshot an OGCAPI - Maps collection from pygeoapi on QGIS

Figure 6 — Screenshot an OGCAPI - Tiles (raster) collection on QGIS

Figure 7 — Screenshot an OGCAPI - Coverages collection on QGIS

More details about the setup for testing this functionality can be found on this issue.

3.4.4.  OpenLayers

TBA

3.4.5.  Geonovum JSON Linter

We took the existing JSON-FG linter and renamed it to the OGC-Checker. We added OGC API Features part 1 functionality and a small portion of the OGC API Common standard. The tool is now capable of automatically discovering which conformance classes are implemented and can apply the appropriate rulesets for validation based on that. This allows us to add other OGC API standards in the future. With this, we’ve taken the first step toward making the linter/validator more generic. The results can be found here: https://github.com/Geonovum-labs/ogc-checker, a live demo is available here: https://geonovum-labs.github.io/ogc-checker/#/ogc-api Testing the linter on examples of OGC API features resulted in discovering several small issues that were resolved by Clemens during the codesprint.

3.4.6.  OSGeo pygeoapi

pygeoapi is a Python server implementation of the OGC API suite of Standards. The project emerged as part of the next generation OGC API efforts in 2018 and provides the capability for organizations to deploy a RESTful OGC API endpoint using OpenAPI, GeoJSON, and HTML. pygeoapi is open source and released under an MIT license. pygeoapi is an official OSGeo Project as well as an OGC Reference Implementation. pygeoapi supports numerous OGC API Standards. The official documentation provides an overview of all supported standards.

3.4.7.  OSGeo pygeometa

pygeometa provides a lightweight and Pythonic approach for users to easily create geospatial metadata in standards-based formats using simple configuration files called Metadata Control Files (MCF). The software has minimal dependencies (the installation is less than 50 kB), and provides a flexible extension mechanism leveraging the Jinja2 templating system. Leveraging the simple but powerful YAML format, pygeometa can generate metadata in numerous standards. Users can also create their own custom metadata formats which can be plugged into pygeometa for custom metadata format output. pygeometa is open source and released under an MIT license.

For developers, pygeometa provides a Pythonic API that allows developers to tightly couple metadata generation within their systems and integrate nicely into metadata production pipelines.

The project supports various metadata formats out of the box including ISO 19115, the WMO Core Metadata Profile, and the WIGOS Metadata Standard. The project also supports the OGC API — Records core record model as well as STAC (Item).

3.4.8.  OSGeo OWSLib

OWSLib is a Python client for OGC Web Services and their related content models. The project is an OSGeo Community project and is released under a BSD 3-Clause License.

OWSLib supports numerous OGC standards, including increasing support for the OGC API suite of standards. The official documentation provides an overview of all supported standards.

3.4.9.  ldproxy

ldproxy is an implementation of the OGC API family of Standards, available under the MPL 2.0 open source license. ldproxy is developed by interactive instruments GmbH, written in Java, and is deployed using Docker containers. ldproxy implements all parts of OGC API — Features, OGC API — Tiles, OGC API — Styles, OGC API — 3D GeoVolumes, and OGC API — Routes. ldproxy is an OGC Reference Implementation for Parts 1 and 2 of OGC API — Features.

3.4.10.  CubeWerx Geospatial Data Server

The CubeWerx Geospatial Data Server (“cubeserv”) is implemented in C and currently implements the following OGC Standards and draft specifications.

The cubeserv executable supports a wide variety of back ends including Oracle, MariaDB, SHAPE files, etc. It also supports a wide array of service-dependent output formats, for example, Geography Markup Language (GML), GeoJSON, Mapbox Vector Tiles, MapMP, as well as several coordinate reference systems.

3.4.11.  GNOSIS Map Server

The GNOSIS Map Server is written in the eC programming language and supports multiple OGC API Standards. GNOSIS Map Server supports multiple encodings including GNOSIS Map Tiles (which can contain either vector data, gridded coverages, imagery, point clouds, or 3D meshes), Mapbox Vector Tiles, GeoJSON, GeoTIFF, GML, and MapML. An experimental server is available online at https://maps.gnosis.earth/ogcapi and has been used in multiple OGC Innovation Program initiatives.

3.4.12.  OpenSensorHub

TBA

3.4.13.  OGC TEAM Engine

TBA

3.4.14.  OGC RAINBOW

TBA

4.1.1.  OGC SensorThings API

TBA

4.1.2.  OGC STAplus — an extension of the OGC SensorThings API

TBA

4.1.3.  OGC API — Features

TBA

4.1.4.  OGC API — Tiles

TBA

4.1.5.  OGC API — Environmental Data Retrieval

TBA

4.1.6.  OGC API — Processes

TBA

4.1.7.  OGC CoverageJSON

TBA

4.2.1.  OGC API — Records

TBA

4.2.2.  OGC API — Coverages

TBA

4.2.3.  OGC Features and Geometries JSON (JSON-FG)

TBA

4.2.4.  OGC Styles and Symbology

During this code sprint, the sprint participants worked on drafting the OGC Styles & Symbology candidate standard. The work included:

A number of GitHub issues were created as a result of this work. This included:

4.3.1.  MapML

Several participants worked on this MapML track.

Rui Cavaco‘s work (in person at code sprint) had three different ‘tracks’:

At first experiments it was clear that MapML itself, and the reference implementation polyfill, show several capabilities which manifest themselves when one goes beyond the simplest OSM tiling examples.

Three examples of this:

The necessity to go through several examples to fully grasp the MapML capability became very clear.

Also became quite clear that it is not crucial to extend polyfill’s functionality, since it is supposed that such functionality should be, sooner or later, transferred to browser’s code bases.

So Rui Cavaco’s final work was dedicated to JavaScript DOM manipulation using, one of MapML’s most interesting features: the ability to, easily, add dynamic changes to web maps. In this case, a real world problem was addressed, the ability to add to and remove from, a web map, at user’s request, some municipal-scale themes from Northern Portugal region.

To this purpose a webapp was built using MapML polyfill from Maps4HTML and Holoviz Panel Python web framework.

Slides describing this work in more detail can be found here. The code repository on GitHub you can find it here.

4.3.2.  ISO 19157-3

TBA

4.4.1.  OSGeo pygeoapi

4.4.1.1.  Mentor stream: Adding a new OGC API to pygeoapi

Given recent updates to pygeoapi in support of API implementation modularity, a mentor stream was given, focusing on adding a new OGC API to pygeoapi. Developers were shown how to add and hook new API functionality / endpoints into the pygeoapi core, as well as exposing via pygeoapi’s OpenAPI functionality. A presentation and example application were demonstrated and made available as proof of concept.

Figure 8

4.4.1.1.1.  OGC API — Processes — Part 2 implementation

An initial prototype was implemented to support the OGC API — Processes — Part 2: Deploy, Replace, Undeploy draft standard. Process creation was implemented by way of ingesting a Common Workflow Language (CWL) definition which referenced a Python application made available as a Docker image. The Python application implemented water body detection, which took as input Copernicus Sentinel-2 or USSG Landsat-9 data and detected water bodies by applying the Otsu thresholding technique on the Normalized Difference Water Index (NDWI)¹. This application was made available as an example in support of the OGC Best Practice for Earth Observation Application Package.

Figure 9

The CWL was published and made available as an OGC API Process. The process description included an executionUnit object providing the CWL definition.

Process execution then invoked the cwltool reference implementation to deploy and run the application in a portable manner, producing a manifest of a STAC Catalog of the NDWI outputs.

Figure 10

The architecture of the implementation can be found below, and the associated implementation on GitHub. Future work includes process replace and delete functionality, as well as describing CWL inputs and outputs as part of the native process description model.

Figure 11

Special thanks is given to the Earth Observation Application Package resources and examples provided on GitHub as well as Gérald Fenoy of GeoLabs SARL for providing valuable explanation, advice and recommendation.

4.4.2.  OSGeo pygeometa

Upon participating in the special track and breakout session focused on Data Quality and Artificial Intelligence, an initial Training Data Markup Language for AI (TrainingDML-AI) encoder was implemented in pygeometa. This enabled configuring a training dataset as a pygeometa metadata control file (MCF) configuration and generating TrainingDataML-AI (or any other metadata format supported by pygeometa). Note that the MCF model was extended to support specifics of TrainingDataML-AI.

The initial exercise illustrated a number of intersections between TrainingDataML-AI and common metadata constructs (spatiotemporal extents, keywords, contacts, data quality, etc.) in support of discovery and documentation. As a result, an additional implementation was put forth to create a TrainingDataML-AI profile of the OGC API — Records — Part 1: Core, Record Core model. This implementation mapped the common metadata constructs into the Record Core model, and encoded TrainingDataML-AI specifics accordingly.

The result of this experiment was the encoding of a training dataset description as a metadata record that could then enable low barrier, broad interoperability via GeoJSON and OGC API — Records.

Figure 12

The resulting implementation can be found on GitHub.

4.4.3.  OSGeo OWSLib

TODO

4.4.4.  ldproxy

TBA

4.4.5.  CubeWerx Geospatial Data Server

TBA

4.4.6.  GNOSIS Map Server

TBA

5.2.1.  TBA

TBA

5.2.2.  TBA

TBA

5.3.1.  Approach

One of the major focuses of the CodeSprint was the use, testing, and enhancement of Training Data Markup Language (TrainingDML). Therefore, this was used as the target standard to test the approach. The example dataset is a simple, reduced and modified version of the dataset link. This is shown below:

{
    "type": "DataQuality",
    "scope": {
      "level": "dataset",
      "levelDescription": [
        {
          "dataset": "main.bld_fts_building"
        }
      ]
    },
    "report": [
      {
        "type": "PositionalAccuracy",
        "measure": {
            "measureIdentification": {
                "code": "FT28_2",
                "authority": "https://defs-dev.opengis.net/vocprez-hosted/object?uri=https%3A//standards.isotc211.org/19157/-3/1/dqc/content/formulaType/"
            },
            "nameOfMeasure": [
                "Absolute Value of mean error to the standard deviation",
                "Horizontal"
            ],
            "measureDescription": "Calculates the mean error of the standard deviation"
        },
        "evaluationMethod": {
          "evaluationMethodDescription": "Uses the standard mathematical formula"
        },
        "result": [
          {
            "quantitativeResult": {
              "value": [
                0.75643
              ],
              "valueUnit": "real"
            }
          }
        ]
      }
    ]
}

Listing 1

The test dataset contains the the PositionalAccuracy element which implements the the measureIdentification element that in turn includes the reference to the authority and a code that corresponds to the data quality formula expressed in MathML. The objective of the software developed in this CodeSprint was to parse the MathML to make it machine readable, machine executable, and parsable. The output was successful to a point of making the formula machine readable, but it was not possible to inject new variables into the formula to execute the chain for another dataset.

6.1.1.  OGC API Standards

TBA

6.1.2.  OGC Encoding Standards

TBA

6.1.3.  MapML

TBA

6.1.4.  Data Quality and Artificial Intelligence

TBA

6.1.5.  Validators

TBA